Defining breakpoints and viewpoints in the software development environment for programmable stream computers

ABSTRACT

A stream computer has a first plurality of interconnected functional units. The functional units are responsive to a data stream containing data and tokens. The data is to be operated on by one or more of the first plurality of interconnected functional units.  
     A second plurality of said interconnected functional units, also part of said stream computer units, are allocated for comparing the data stream with a debug stream to generate debug signals. Reporting logic is responsive to the debug signals for reporting the occurrence of matches between the data stream and the debug stream in a format compatible for human perception.  
     The second plurality of interconnected functional units generate viewpoints and breakpoints in response to similarities between the data streams present within the stream computer and the debug stream. The breakpoint can either interrupt the data stream or let it pass through. Viewpoints do not change the streams they examine.  
     The reporting logic is compatible with a graphical user interface, where the graphical user interface identifies the functional units, input and output streams of each of the functional units.

[0001] This application is a continuation in part of U.S. Patent andTrademark Office application Ser. No. 10,052,082 titled “ReconfigurableProcessor Architectures”.

BACKGROUND OF THE INVENTION

[0002] 1. Field of Invention

[0003] This invention is in the field of software development usingbreakpoints and viewpoints for use in stream computers.

[0004] 2. Description of the Related Art

[0005] Software, the instructions for a computer to follow, arenecessary to perform a particular function and render the computeruseful. Developing a properly executing software package, possiblycomprising thousands of computer instructions, or steps, is an arduoustask. Ideally, in a quality software package, all computer instructionsare correct and in the proper sequence, errors have been identified andcorrected, and desired functions completely implemented.

[0006] In arriving at a quality software package, generally an iterationmethod is used wherein executable instructions, or code, are writteninto registers or memory locations and then presented for execution onthe target computer. After examining results of code execution, itseffects on the registers and memory locations, the code is modified tocorrect any errors that may have been found. Thus, during the softwaredevelopment process, code compatible tools are needed that allow theexamination of various machine states at certain points in the executionof a program to insure that the software is performing the desiredfunction and specified results are reached. Like the oscilloscope is atool allowing the builder of electronic circuits to “see” circuits inoperation, a similar tool is developed for the software engineer. Thistool allows the examination of registers and memory locations followingthe particular execution of one or more instructions thus tracing thechanges brought on by executing the computer instructions.

[0007] In prior art, Von Newman type, central control computers,progress of execution of computer instructions is typically performed byexamining register contents at certain time intervals corresponding toevents chosen by the programmer. These events are defined with the aidof a a compiler or other software tool having the capability of stoppingexecution and presenting the specific contents of registers and memorylocations for inspection and evaluation.

[0008] Prior art software tools allowing the step by step examination ofregisters and memory location in Von Newman architecture computers arewell known. However, with the advent of distributed, stream computersdescribed in the parent application, the software tools relevant insingle central processing unit (CPU) Von Newman architectures are nolonger applicable, in fact, impossible to use. The prior art toolsdepend on a central entity, the central processing unit to transfer andprocess information between various parts of a computer. Thus, this onecentral entity, is responsible for program progress and is the area tobe monitored. In this invention, in contrast, there are pluralities ofindependent processing entities, having no relationship to the VonNewman structure, function or concept.

SUMMARY OF THE INVENTION

[0009] Above limitations are solved by the present invention by a streamcomputer, said stream computer comprising a first plurality ofinterconnected functional units. The functional units are responsive toa data stream containing data and tokens. The data is to be operated onby one or more of said first plurality of interconnected functionalunits.

[0010] A second plurality of said interconnected functional units, alsopart of said stream computer, are allocated for comparing said datastream with a debug stream to generate debug signals. Reporting logic isresponsive to the debug signals for reporting the occurrence of matchesbetween said data stream and said debug stream in a format compatiblefor human perception.

[0011] The second plurality of interconnected functional units generateviewpoints and breakpoints in response to similarities between the datastreams present within said stream computer and the debug stream(s). Thebreakpoint can either interrupt the data stream or pass it through.Viewpoints do not change the streams they examine, but only extractinformation therefrom matching said debug stream.

[0012] The reporting logic is compatible with a graphical userinterface, where the graphical user interface identifies the functionalunits, inputs and outputs (streams) to or from the functional units, aswell as streams between the functional units.

BRIEF DESCRIPTION OF THE DRAWING

[0013] In the Drawing:

[0014]FIG. 1 is an exemplary configuration of prior art Von Newman,single control computer architecture.

[0015]FIG. 2 is an exemplary graphic representation of a problem to besolved using stream computers;

[0016]FIG. 3 is an exemplary user defined function of the problem inFIG. 2 via a graphical interface;

[0017]FIG. 4 is the user defined function of FIG. 3, further refined andready to run on a target computer or compatible simulator;

[0018]FIG. 5 shows a typical breakpoints and viewpoints depiction forthe Graphical Programming Environment of this invention for the problemof FIG. 4;

[0019]FIG. 6 shows details of breakpoint and viewpoints applied to theexemplary stream computer described herein;

[0020]FIG. 7 shows an example of digital logic implementing a breakpointapplicable to this invention;

[0021]FIG. 8 shows an example of digital logic implementing a viewpointapplicable to this invention;

[0022]FIG. 9 shows an example of allocating part of a stream computer toimplement the digital logic required to generate breakpoints andviewpoints.

DETAILED DESCRIPTION

[0023] The present invention describes an apparatus and method ofinducing breakpoints and initiating viewpoints during the programming ofa stream computer.

[0024] The stream computer comprises a first plurality of interconnectedfunctional units. The functional units are responsive to a data streamcontaining data and tokens. The data is to be operated on by one or moreof said first plurality of interconnected functional units.

[0025] A second plurality of said interconnected functional units, alsopart of said stream computer, are allocated for comparing said datastream, as well as other streams internal to the computer, with a debugstream to generate debug signals. Reporting logic is responsive to thedebug signals for reporting the occurrence of matches between said datastream and said debug stream in a format compatible for humanperception.

[0026] The second plurality of interconnected functional units generateviewpoints and breakpoints in response to similarities between the datastreams present within said stream computer and the debug stream(s). Thebreakpoint can either interrupts the data stream or pass it through.Viewpoints do not change the streams they examine.

[0027] The reporting logic is compatible with a graphical userinterface, where the graphical user interface has symbols identifying inhuman compatible format the functional units, and inputs and outputs(streams) to or from the functional units.

[0028] Stream computers are collections of functional units (nodes)operationally interconnected via software streams in addition tohardware links. More specifically, stream computers comprise a pluralityof similar functional units where the specification of the computer (andthe programming thereof) is defined by the operations performed by thefunctional units and the streams (also known as data flows) thatconnect, or traverse the functional units. Thus, the specification of acomputer program for stream computers is defined by the operationsperformed by the functional units and the streams (also known as dataflows) that connect the functional units.

[0029] The functional units perform prescribed operations on theinput(s) and create output(s) when all inputs are valid and the outputflow can accept the output. The software streams flowing betweenfunctional units contain data, for example, integer data. Some streamcomputers also have control/token information as part of the data,generally at most a few bits, or a small percentage of the data bits.This control/token information also flows along with the data betweenfunctional units. The token information is not operated on (e.g. added,multiplied) but rather is used to determine what operation thefunctional units perform.

[0030] In contrast to stream computers, FIG. 1 is an exemplary VonNewman computer structure of the prior art. A control unit 107 monitorsthe transfer of digital information between memory 101, Arithmetic andLogic Unit (ALU) 103, and Input/Output unit 105. Typically, control unit107 will instruct ALU 103 to fetch contents of a particular locationwithin memory 101, perform a mathematical or logical operation on theretrieved data, then write the results at another location within memory101. Control unit 107 can interpret an instruction retrieved from memory101 and select alternative courses of action based on the results ofprevious operations. Memory 101 contains both data and instructions tobe followed by control unit 107 and/or ALU 103. The instructions can befollowed in any order. Similarly, control unit 107 will instructInput/Output (I/O) unit 105 to make ready data for ALU 103 to read.Thus, for software development purposes, monitoring control unit 107,contents of memory 101 and I/O 105 will suffice to ascertain the stateof the computer on a step by step basis and monitor progress of programexecution. Compilers of the prior art provide break points within asequence of executed steps by control unit 107. The break pointstypically halt the execution of program steps within control unit 107and list contents of certain locations within memory 101 for inspectionand reconciliation with expected values. In Von Newman architectures,there is no flow of data to a plurality of functional units, eachcapable of computing the required results. Von Newman architectures canbe viewed as having centralized control, while stream computersrepresent a distributed structure with much duplication of individualfunctional units where each functional unit reacts independently of theothers and computes results under control of flowing data and tokens.

[0031] To accommodate the distributed nature of stream computers, andfacilitate software development for them, this invention insertsbreakpoint and viewpoint logic into the definition (or program) of aprogrammable stream computer. This functionality is best implemented ina graphical programming environment and the examples illustrating thebest mode of the invention use such an environment.

[0032] The examples in this invention are illustrated by the use of asimple polynomial equation to illustrate the characteristics of thisinvention. Typically a large number, perhaps hundreds, of functionalunits exemplified below are interconnected to compute Fast FourierTransforms, or matched filter functions.

[0033] A simple, general illustrative equation is used:

Y=PX ² +QX+R

[0034] where P, Q, R and X are inputs and Y is the output. Forsimplicity, X and Y are the only dynamic data streams and P, Q, and Rare constants (i.e. registers preloaded with constant values) whereas anew value of X is potentially available on the input stream for everyclock pulse.

[0035] As shown in FIG. 2, in this example, the fundamental (primitive)functional unit in the sample computer is a functional unit 202 capableof performing a multiplication in multiplier 206 and an addition inadder 208. The results from multiplier 206 are combined with an additionin adder 208. While this example shows a multiplier 206 and adder 208,any other functions can be substituted, depending on computationalneeds.

[0036] Functional unit 202 is shown by the dashed line and in laterfigures will be identified as a MUL. Functional unit 204 is structurallysimilar to functional unit 202, having a multiplier 212 and adder 214 togenerate an output Y.

[0037] Delay 210 applied to X matches the delay experienced infunctional unit 202. Without delay 210, X would be presented tofunctional unit 204 before the result from functional unit 202, PX+Q,was ready. This facilitates keeping the pipeline full.

[0038] From the diagram in FIG. 2, the output Y is the result ofPX²+QX+R, as computed by functional units 202 and 204.

[0039] Breakpoints and Viewpoints

[0040] In a graphical programming environment to be used with thisinvention, the user graphically represents the function being performed.In this example, as shown in FIG. 3, a user defined function for thesame equation as in FIG. 2 Y=PX²+QX+R is being defined. In the graphicalinterface, MUL 301 is the hardware functional unit 202, while MUL 303 isthe hardware functional unit 303. The delay 305 for X is also providedto facilitate the operation of the pipeline.

[0041] In the graphical interface, for this example, the user selectseach data flow and selects the data types. The user also selects thefunction and specifies the function to be performed by MUL 301 and MUL303. In this case, the function of MUL 301 and MUL 303 is a multiplywith an add.

[0042] Typically, having completed the specification of the functionalunits, the specification will be executed on a simulator or directly inhardware. The graphical representation shown in FIG. 4, is an example ofthe structure of FIG. 3. The graphical representation is compiled togenerate an executable program. The executable to compute Y=2X²+3X+4 isthen run on a target computer or simulator. The details of compilationof a specification, and running the compilation on a target (whetherreal hardware or a simulation) are well known, and therefore notdetailed further.

[0043] The development environment of this invention inserts thebreakpoint and viewpoint specifications into the executable programgenerated from FIG. 4. The breakpoint and viewpoint specifications areloaded as part of the program image in FIG. 5. The capabilities arefully programmable. The graphical programming environment incorporatesthe details. The programmer sees the view as shown in FIG. 5. The othermechanistic, underlying details are conveniently shielded from the userto facilitate the development process.

[0044] Once a breakpoint and/or viewpoint is defined, the graphicalinterface saves the definition but allows the user to determine whetheror not specific breakpoints and viewpoints are incorporated into thespecific program image being created.

[0045] The graphical programming environment is tied to the target asshown in FIG. 4. FIG. 4 shows the combination of functions MUL readingthe X values from a file, source of X values 402, and deposits the Youtputs into another file, or storage means, store results Y 404. Thespecification defines the values of P, Q, and R to be 2, 3, and 4respectively, so that the sample equation now becomes

Y=2X ²+3X+4

[0046] When the user runs this program the input file in 402 is read andthe output file in 404 is written. If the programmer has incorrectlyspecified the function to be performed by one or both functional units(identified as MUL in the graphic interface) 301 and 303 units then theoutput Y may not be as expected. That is, there may be an error in theprogram. With an error present, the programmer inserts a breakpoint inan attempt to locate the error. This invention allows a breakpoint to beinserted on any data stream. Therefore, the user can select the inputstream X, the stream flowing between MUL units 301 and 303, or theoutput stream Y. Since each stream has two components, namely data andtoken, the user is able to select a combination of the two. For example,a condition for generating a breakpoint is defined by:

[0047] a) when the data is greater than zero and

[0048] b) the token equals zero.

[0049] The capabilities of the stream computer functional units willdefine the set of available breakpoint conditions. However, thebreakpoint function can use one or more functional units. The number ofbreakpoint functions is only limited by the number of programmablefunctional units and connectivity defined by the programmable streamcomputer.

[0050] In the example of FIG. 5, the programmer introduces a breakpointtriggered by the data stream between MUL 301 and MUL 303 having a valueof 1. The programmer also wants to view the X input stream to the secondMUL 303 after delay 305. For the example shown, the corresponding valueof X is −1. FIG. 5 shows how the user specifies this breakpointgraphically using the graphic interface. Breakpoint 501 specifies thedata condition and token condition. Data condition for breakpoint 501 isD: 1 while token condition is T: ANY. The AND function indicates thatboth conditions must be met for a breakpoint to be triggered.

[0051] Viewpoint 503 indicates the condition necessary to generate aviewpoint. For example, the data value 0 is shown, followed by asemicolon, and then the token value 0.

[0052] Viewpoint 505 monitors the stream of X, after delay 305, beforeentering MUL 303. The viewpoint is triggered when the data value is 0and token value is also 0.

[0053] The display of the graphic interface shields the programmer fromthe underlying details and facilitates the programming process. FIG. 6shows an exemplary implementation for the breakpoints shown in FIG. 5using a similar level of abstraction. In FIG. 6, viewpoints 604, and 606and breakpoint 602 are interposed to examine the data streams from MUL301 and into MUL 303.

[0054]FIG. 7 shows an example of a breakpoint implementation applicableto this invention. The breakpoint uses digital logic and uses anindependent stream (the debug stream) to perform comparisons andidentify the occurrence of a condition for triggering the breakpoint. Inthis digital logic, ALU 701 compares a debug stream and breakpointnumber and stores results in a memory 703. The quantities stored inmemory 703 are compared by ALU 705 with the data stream to identify abreakpoint.

[0055] The structure the digital logic made of ALU 701, memory 703 andALU 705 used to identify the breakpoint is the same as that used withinthe functional units. An ALU is the same functionally, and can be thesame as a MUL functional unit without the multiply capability, as shownin FIGS. 6 and 7. The debug stream carries information to the digitallogic and enables output of the results.

[0056] Because the functional units have the same structure required forbreakpoint generation, a programmer has the option to allocate part ofthe stream computer resources for breakpoint generation, on a case bycase basis. If breakpoints are specified in the program, they requirevaluable resources within the stream computer, namely streams andfunctional units.

[0057] In the example shown in FIG. 7, the input to initiate abreakpoint is a debug stream that will indicate whether the breakpointis enabled. A combination of data and token can be used. For example,the data may be a unique identifier for each breakpoint so that morethan one can be used. The output stream will indicate if the breakpointhas been triggered or else it will pass along the input. The viewpointsthen take this information (also passing it along for downstreamviewpoints) and act accordingly. If the breakpoint has been triggered,then on the first available clock it may forward breakpoint triggerinformation.

[0058] On the next clock cycle, the digital logic of FIG. 7 may outputthe identifier of the viewpoint and then finally the value of theviewpoint to a reporting logic. The token values that are input to andoutput by the viewpoints are:

[0059] null (data is invalid);

[0060] breakpoint (data is the address of the breakpoint andenable/disable/trigger data);

[0061] viewpoint identifier (data is the viewpoint identifier);

[0062] viewpoint value (the data is the value of the viewpoint).

[0063] The Breakpoint in FIG. 7 is implemented by having ALU 701 and 705compare the debug stream input. If the token indicates breakpoint, ALU701 will detect if the breakpoint number (a constant) is a match, if soit will output a breakpoint hit. This detection by ALU 701 controlsdigital logic that will generate output that is the same as this inputuntil a breakpoint is hit. If a breakpoint has been hit then the digitallogic will neither consume the input (causing upstream functions tostop), nor produce output causing downstream functions to stop. Thisinformation also continues down the debug stream to viewpoints so theywill output their data.

[0064] The viewpoint in FIG. 8 is implemented by splitting the datastream and always forwarding it unchanged. The digital logic on thedebug stream, viewpoint ALU 802, looks to see if any breakpoint has beendetected. If so, the digital logic will insert its viewpoint identifierand data stream values into the debug stream at the first availableopportunity and will continue to do so until no data stream informationis available or the breakpoint is released. Memory 804 provides theincoming data stream to viewpoint ALU 802 for viewpoint detection inaccordance with the debug stream, as well as passing the data streamunchanged to the next stage or functional unit.

[0065] These implementations are examples indicative of the concept ofthe invention. The exact implementation will be a function of thecapabilities of the functional units and available stream connectivityin the system. Breakpoints and viewpoints are implemented using the sameprogrammable functional capabilities as the typical, normal functionunits available within a stream computer. These functions are insertedinto the program of the stream computer the same as any otherfunctionality. Because of this and the fact that no special debugcapabilities are required and that generally differ in hardware versus asimulation, there will be a consistent implementation in the simulationand the target thereby easing program development.

[0066] This invention does not preclude special debug capabilities, butrather frees the software development engineer from relying on them.This differs from the prior art because most processors require andimplement special functions to support debugging. Using this paradigm nospecial capabilities are required, although the system does require somefunctional units to be available for debug. However, having spare unitswould be normal during unit testing where small fragments of the overallprogram are being tested.

[0067] The concept is further summarized using the concepts from FIG. 2to FIG. 8 in a simple example shown in FIG. 9. Here, functional units901, 903, 905, 907, 909, 911, 913, 915 and 917 form a stream computerand have access to the data and token stream. Of these, functional units905 and 911 are allocated to process breakpoint/viewpoint generation.Functional units 905 and 911 form digital logic 919 required tointerpret a debug stream. Functional units 905 and 911 are cooperativelyassociated with, for example, functional units 903 and 909 respectively,in that the data stream through 903 and 909 are monitored by 905 and 911respectively.

[0068] The results from digital logic 919 are transferred to reportinglogic 921 for conversion to a format compatible with the display ofbreakpoints, viewpoints and associated data stream content 923. Ineffect, functional units 905 and 911, part of the stream computer areprogrammed to respond to the debug stream and the data/token stream fordebugging purposes. It is envisioned that the functional units making upthe stream computer as well as reporting logic 921 are integrated on asingle semiconductor or hybrid substrate to minimize size and cost.

[0069] The structure of the stream computer applicable herein isdiscussed in the parent application, and is incorporated herein in itsentirety.

[0070] Although presented in exemplary fashion employing specificembodiments, the disclosed structures are not intended to be so limited.For example, although a multiply and add function is shown as a buildingblock example, any other combination of mathematical or Boolean logicoperation could benefit from the concepts described by the inventionherein.

[0071] Those skilled in the art will also appreciate that numerouschanges and modifications could be made to the embodiment describedherein without departing in any way from the invention. These changesand modifications and all obvious variations of the disclosed embodimentare intended to be embraced by the claims to the limits set by law.

I claim:
 1. A stream computer, said stream computer comprising: aplurality of interconnected functional units, each of said functionalunits responsive to a data stream containing data to be operated on byone or more of said functional units; digital logic cooperativelyassociated with one of said functional units for comparing said datastream presented to said one of said functional units with a debugstream; reporting logic associated with said digital logic for reportingthe occurrence of matches between said data stream and said debugstream.
 2. A stream computer as described in claim 1 wherein saiddigital logic extracts similarities between said data stream and saiddebug stream to generate a viewpoint.
 3. A stream computer as describedin claim 2 wherein said digital logic generates said viewpoint withoutinterrupting said data stream.
 4. A stream computer as described inclaim 1 wherein said digital logic extracts similarities between saiddata stream and said debug stream to induce a breakpoint.
 5. A streamcomputer as described in claim 4 wherein said digital logic extractssimilarities between said data stream and said debug stream to inducesaid breakpoint in response to a breakpoint number arriving at saiddigital logic.
 6. A stream computer as described in claim 4 wherein saiddigital logic generates said breakpoint and interrupts said data streampassing through said digital logic.
 7. A stream computer as described inclaim 4 wherein said digital logic generates said breakpoint and allowssaid data stream to pass through.
 8. A stream computer as described inclaim 1 wherein said at least one of said plurality of interconnectedfunctional units, said digital logic, and said reporting logic areintegrated on a single substrate.
 9. A stream computer as described inclaim 1 wherein said reporting logic are compatible with a graphicaluser interface, said graphical user interface identifying saidfunctional units, and inputs and outputs of said functional units.
 10. Astream computer as described in claim 1 wherein one or more of saidfunctional units are reconfigured to become part of said digital logic.11. A stream computer as described in claim 1 wherein said digital logicfurther comprises arithmetic logic units (ALU) and memory functions,said functions obtained by allocating some functional units to performsaid ALU and memory functions.
 12. A stream computer, said streamcomputer comprising: a first plurality of interconnected functionalunits, said functional units responsive to a data stream containing dataand tokens to be operated on by one or more of said first plurality ofinterconnected functional units; a second plurality of saidinterconnected functional units allocated for comparing said datastream, and internal streams within said stream computer, with a debugstream to generate debug signals; reporting logic responsive to saiddebug signals for reporting the occurrence of matches between said datastream and said debug stream compatible with human perception.
 13. Astream computer as described in claim 12 wherein said second pluralityof interconnected functional units extracts similarities between saiddata stream and said debug stream to generate a viewpoint.
 14. A streamcomputer as described in claim 13 wherein said second plurality ofinterconnected functional units generates said viewpoint withoutinterrupting said data stream.
 15. A stream computer as described inclaim 12 wherein said second plurality of interconnected functionalunits extracts similarities between said data stream and said debugstream to induce a breakpoint.
 16. A stream computer as described inclaim 15 wherein said second plurality of interconnected functionalunits extracts similarities between said data stream and said debugstream to induce said breakpoint in response to a breakpoint number. 17.A stream computer as described in claim 15 wherein said second pluralityof interconnected functional units generates said breakpoint andinterrupts said data stream.
 18. A stream computer as described in claim15 wherein said second plurality of interconnected functional unitsgenerates said breakpoint and allows said data stream to pass through.19. A stream computer as described in claim 12 wherein at least one ofsaid plurality of interconnected functional units, and said reportinglogic are integrated on a single substrate.
 20. A stream computer asdescribed in claim 12 wherein said reporting logic is compatible with agraphical user interface, said graphical user interface identifying saidfunctional units, and inputs and outputs of said functional units.
 21. Amethod for operating a stream computer, said method comprising the stepsof: programming a first plurality of interconnected functional unitsforming said stream computer to compute in accordance with data andtoken contained in a data stream; programming a second plurality of saidinterconnected functional units forming said stream computer to comparesaid data stream, and internal streams within said stream computer, witha debug stream; reporting the occurrence of matches between said datastream and said debug stream using symbols compatible with humanperception.
 22. A method as described in claim 21 further including thestep of extracting similarities between said data stream and said debugstream to generate a viewpoint, using said second plurality ofinterconnected functional units.
 23. A method as described in claim 22wherein said step of extracting similarities by said second plurality ofinterconnected functional units generates said viewpoint withoutinterrupting said data stream.
 24. A method as described in claim 21wherein said step of extracting similarities by said second plurality ofinterconnected functional units between said data stream and said debugstream induces a breakpoint.
 25. A method as described in claim 24wherein said step of extracting similarities by said second plurality ofinterconnected functional units also induces said breakpoint in responseto a breakpoint number.
 26. A method as described in claim 24 whereininducing said breakpoint interrupts said data stream.
 27. A method asdescribed in claim 24 wherein inducing said breakpoint allows said datastream to pass through.
 28. A method as described in claim 21 computerwherein said reporting step generates information compatible with agraphical user interface, said graphical user interface identifying saidfunctional units, and inputs and outputs of said functional units.